A typical conventional database system includes a database for holding data and a database management system (DBMS) for managing the database. The DBMS performs multiple management functions, including the regulation of access to the data contained within the database.
With the increasing popularity of the Internet, many conventional database systems have sought to provide access to clients over an Internet connection. Such database systems often work in conjunction with “application servers.” An application server is a program situated between a client and a resource, such as a database, that handles operations between the client and the server resource. The application server may run programs that assist the client in gaining access to a database from a browser-based environment. Application programs running on client systems typically interact with applications running on the application server by making calls to methods defined in an application program interface (API). The API is a formalized set of methods that can be referenced by an application program to access services.
With conventional systems, designing an API is a difficult task. It is difficult for developers to decide which methods are to be included in an API. The API methods should be sufficiently general so that developers can readily employ them in a variety of customized applications. However, the developer faces a dilemma in that the developer does not know which applications will ultimately use the API. Consequently, the developer has little basis for designing an API that is customized for a given application program.
In the past, developers have addressed this problem by providing APIs in which generic services perform elementary operations that are usable in virtually any application program. In addition, developers have typically designed the API services so that there is little, if any, overlap in their functions. A disadvantage of this approach is that such APIs are “one-size-fits-all” APIs that are not tailored to the specific needs of any one application program.
In general, an API serves as a vehicle through which two separate processes can communicate. Consequently, each invocation of an API method generally requires interaction between processes. Where the interacting processes reside on the same physical machine, this interaction is unlikely to degrade system performance. However, in modern n-tiered systems, the interacting processes reside on different physical machines. Hence, each interaction between the two processes requires access to a network or other communication path between these two physical machines. This contributes to increased latency in the n-tiered system.
It is possible to design, by hand, an optimized API that minimizes the number of communications sent over a network. Unfortunately, this labor-intensive task requires that the developer be familiar with the logic flow for application programs that, in many cases, have yet to be written. Moreover, any changes to the logic flow of the application program may, depending on their extent, require corresponding changes in an API customized for that application program.
It is thus an object of the invention to overcome these disadvantages by providing a method and system for the automatic generation of an API optimized for a particular application.